The session initiation protocol (“SIP”) is an application-layer control protocol that can establish, modify and terminate multimedia sessions (also referred to as “conferences”) or Internet telephony calls. SIP is defined in RFC2543. SIP can invite participants to unicast and multicast conferences and does not require that the initiator be a member of the conference to which it is sending invitations. Media and participants can be added to an existing session. SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal mobility, which provides the ability to reach a called party at a single, location-independent address.
As a traditional text-based Internet protocol, it resembles the hypertext transfer protocol (“HTTP”) and simple mail transfer protocol (“SMTP”). Like these protocols, SIP is a textual protocol based on the client-server model, with requests generated by one entity (the client), and sent to a receiving entity (the server) which responds the requests. A request invokes a method on the server and can be sent either over the transmission control protocol (“TCP”) or the user datagram protocol (“UDP”). The most important SIP method (there are currently six) is the INVITE method, used to initiate a call between a client and a server. The other SIP methods are ACK, OPTIONS, BYE, CANCEL and REGISTER. A new INFO method has also been proposed as part of SIP-extensions and is detailed in RFC 2976.
SIP uses session description protocol (“SDP”) for media description. SIP supports five aspects of establishing and terminating multimedia communications; which are user location, user capabilities, user availability, call setup and call handling.
SIP messages are typically either requests or responses. Requests flow from a client to a server and responses flow from a server to a client. These requests and responses include different headers to describe the details of the communication. SIP header fields are similar to HTTP header fields in both syntax and semantics. Messages use header fields to specify such things as caller, callee, path of the message, type and length of the message body and so on. Some of the header fields are used in all messages, the rest are used when appropriate. The order in which the headers appear is generally not important, except that the VIA field and the HOP-BY-HOP headers must appear before END-TO-END headers.
The VIA field indicates the path followed by a message (either a request or a response) so far. Typical examples of the VIA field in both SIP requests and responses are shown in FIGS. 1 and 2. The VIA field is one of the header fields that is required in all SIP messages. One significant disadvantage of SIP when used for 3G wireless communications is that the signaling overhead severely increases call setup time for real time applications. To address this problem, the industry has produced some limited signaling compression utilities, namely SIGCOMP. However, SIGCOMP still suffers from an inability to provide compression on many of fields found in signaling messages. In particular, the VIA field is required in all SIP messages and can grow to be quite large as a message follows a lengthy path from sender to recipient. The VIA field cannot be compressed. Accordingly, the industry has a need for a solution that overcomes these significant problems found in conventional SIP messaging as described above.